背景故事
今天我們來聊聊大家很在意的其中一種數字：效能。Kafka身為一個大型的分散式系統一定分分秒秒保證吞吐量，但身為一個優秀的軟體工程師，我們不看文件更不相信任何一個系統保證的數字，因此要如何檢查手上的Kafka到底能提供怎樣的效能就是一個很重要的事情。當然Kafka非常清楚知道每個使用者的需求，因此我們也有提供官方的效能評測工具，也就是ProducerPerformance，這個工具其實並不複雜，主要的邏輯就是啟動一個producer然後不斷送出資料並且在過程中紀錄顯示一些效能數字，最後在使用者指定的資料量都完成後就結束任務。
聽起來是個很簡單的事情，對吧？這樣說來到底為什麼需要這隻KIP呢？首先我們來思考一下如果是你在跑效能評測，你會想看到哪些數字 ... 抱歉，更正一下，你會想看到哪個階段的哪個數字？等等，為什麼我會說哪個階段？這是因為producer是需要時間來進入狀況，進入可以全心全意送資料的狀況，就像球員需要熱身一樣，producer在真正可以開始送資料之前，其實需要先完成一些準備工作，例如要取得叢集的資訊、完成節點之間的連線確認等等，這些行為在小叢集可能是一瞬間的事情，但是在大型叢集可能是一個需要一點點時間的準備工作。所以如果這個階段的效能指標也被納入考量，那很可能就會導致我們誤判producer的效能。
講到這裏，你應該懂了一些，但又有更多疑惑，你心裡可能會想說就算準備階段再怎麼慢，都只佔整體測試過程的一小小部分，就算不小心納入數字又能怎樣影響最後結果？那這裏就要提出在效能評測時我們也很在意的一個數字，那就是最糟糕的狀況表現，也就是在整個測試過程中最慘的效能能夠有多慘，知道所謂的下限可以讓我們對系統有更多的認知，例如我們可以給出承諾資料最多的延遲是多少，這在評估應用和硬體的需求時會非常非常的有幫助，雖然最慘的狀況不會是常態，但如果你的系統沒有對最慘的狀態做準備，很有可能在最慘狀況發生時手足無措，進而讓你的升遷也跟著手足無措。
因此KIP-1052要帶來的改變就至關重要，它嘗試將準備時間的評估獨立出來，讓使用者可以明確知道準備階段的效能數字以外，也可以看到準備完成後開始的效能數字，這樣使用者就可以對producer的表現更有掌握！
解決辦法
既然知道要隔離準備時間的統計數字，那首要就是要讓ProducerPerformance能知道什麼時候是準備期間、什麼時候是熱身完成。目前KIP-1052傾向直接新增一個參數讓ProducerPerformance先送出一定量的資料，然後再送這些一定量的資料的階段就是所謂的準備時間，這個階段完成後再送的資料才會是我們主要觀察的效能指標。講到這裏，大家心理可能也會有疑惑，那我們要怎麼知道那些資料送完熱身就完成了？以及使用者要怎麼指定熱身用的資料量？準備得太多就是浪費時間、準備得太少會導致ProducerPerformance的效能評估摻入熱身期間的數字。沒錯，筆者也有同樣的疑問，因此筆者在討論串裡面提出一個想法，那就是我們不指定熱身的數量，而是改成一個標誌，如果該標誌啟動也就是使用者希望要隔離熱身的數字，那麼ProducerPerformance一樣會不斷的送出熱身用的資料，直到ProducerPerformance自己評估熱身已經完成，那麼該如何評估呢？正如上面提到熱身會做的幾件事情，metadata的同步以及建立節點之間的連線，只有這幾個條件都達到，ProducerPerformance才可以離開熱身的階段開始正式的效能評估
廣告
歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術
iThome鐵人賽
看影片追技術